Unified communications services (UCS) are known. Typically, these services comprise a number of networked application processes that provide voice, text, data, messaging, and other communications services to one or more subscribers. For example, application processes such as electronic mail (email), voice mail, instant messaging, document management databases and other database processes, may all be networked in a UCS to enable subscribers to communicate and otherwise share information.
One drawback of existing UCS systems is that notification services (e.g., alerting a subscriber that a voice message is waiting, or the like) operate using some type of polling architecture. For example, each subscriber may create a subscriber profile that contains a number of criteria pertaining to how notification services are to deliver alerts. The system will periodically poll through the profiles to determine whether alerts should be sent. Under a polling system it is necessary to either poll frequently to ensure that alerts are timely sent, or accept a delay (defined by the polling cycle time) in sending alerts. Either scenario may be less than desirable.
Another drawback of existing systems is that notification services often do not provide for filtering, or do not provide for multi-level filtering, of notification alerts. Thus, processing of notification alerts can be inefficient.
Another drawback of existing systems is that the notification services are often not extensible to new or additional application processes. Under such systems implementing new or additional application processes over the UCS network is problematic or, even worse, impossible.
Other drawbacks, such as an inherent lack of scalability and duplicated notification mechanisms for different events, exist with present systems.